feat: create minimal global config using app.manifest and app.conf#1625
feat: create minimal global config using app.manifest and app.conf#1625hetangmodi-crest wants to merge 18 commits intodevelopfrom
Conversation
| from ..file_generator import FileGenerator | ||
|
|
||
|
|
||
| class GlobalConfigGenerator(FileGenerator): |
There was a problem hiding this comment.
Can MinimalGlobalConfig inherit FileGenerator directly without this middleware?
There was a problem hiding this comment.
I did think about it, but didn't proceed with it as I thought we might move the ucc-gen init command to generate globalConfig with this hierarchy, just to keep everything in same umbrella.
There was a problem hiding this comment.
I think we can make it much simpler but inheriting directly, this way we can avoid having tests/unit/generators/globalConfig_generator/test_globalConfig_generator.py at all.
We can always refactor it later if we need to bring in another feature.
tests/unit/generators/globalConfig_generator/test_create_minimal_globalConfig.py
Outdated
Show resolved
Hide resolved
| return "test_addon" | ||
|
|
||
|
|
||
| @patch("addonfactory_splunk_conf_parser_lib.TABConfigParser") |
There was a problem hiding this comment.
Why are we patching TABConfigParser?
There was a problem hiding this comment.
Since _set_attributes utilizes TABConfigParser to read app.conf and we do not have an actual app.conf, I have mocked it this.
There was a problem hiding this comment.
This test case tests the internal implementation.
I'd like to see the complete unit test for this functionality. If we need app.manifest and app.conf files for this to work, I'd like to see the following test:
app_conf = AppConf("...")
app_manifest = AppManifest("...")
minimal_global_config = MinimalGlobalConfig(
...,
app_conf,
app_manifest,
)
If we can't write a test like this right now - we need to refactor our code urgently.
There was a problem hiding this comment.
Same with the test_generate_minimal_gc test case in this file. I would like to see the test verifying the result after running the code rather than verifying how many time something was called.
tests/unit/generators/globalConfig_generator/test_globalConfig_generator.py
Outdated
Show resolved
Hide resolved
| @@ -0,0 +1,12 @@ | |||
| def test___init__html(): | |||
There was a problem hiding this comment.
What is the purpose of this test?
There was a problem hiding this comment.
To ensure that only expected classes and modules exist in globalConfig_generator
There was a problem hiding this comment.
Those modules and classes are internal, I do not expect them to be used by some other program from the outside world so I do not see a lot of value in keeping those tests.
| import addonfactory_splunk_conf_parser_lib as conf_parser | ||
|
|
||
|
|
||
| class MinimalGlobalConfig(GlobalConfigGenerator): |
There was a problem hiding this comment.
Hm, would it make sense for this logic to be part of an existing globalConfig? This breaks the whole integration with ...Generator classes but it would be consistent with the existing class.
There was a problem hiding this comment.
The idea was, since we are generating globalConfig, I kept it under ...Generator class. Moreover, if we move it to GlobalConfig class of global_config.py, we would be updating the behaviour of that class - currently, it is to parse a globalConfig and convert it to a dictionary and provide properties to access various attributes. Moving this implementation there, this class would be responsible to create a physical globalConfig file (if not present) and then continue with the current behaviour. Additionally, we would require to give the source_dir path (which induces additional changes in the tests).
There was a problem hiding this comment.
I see 2 benefits of having a class MinimalGlobalConfig inherit FileGenerator.
First - we will get our documentation page updated automatically. Second - we could eventually compare generated files by us and what's in the package.
First benefit is nice to have but totally optional. Second one is absolutely great but is not applicable to the globalConfig itself.
I would imaging GlobalConfig to have a classmethod from_app_conf_and_app_manifest (the name is not the best, I agree), accept an instance of app.conf and app.manifest files as classes and produce a GlobalConfig class as a result which can be written somewhere later.
There was a problem hiding this comment.
Migrated the implementation from Filegenerator to GlobalConfig class.
| self._original_path = global_config_path | ||
| self.user_defined_handlers = UserDefinedRestHandlers() | ||
|
|
||
| def generate_minimal_globalconfig( |
There was a problem hiding this comment.
I was thinking more about something like in this PR - #1655. We introduce the second way to initialize the GlobalConfig class which takes an instance of AppConf and an instance of AppManifest classes and should return GlobalConfig as a result. We do not need to dump it straight in this method, we have dump method in the GlobalConfig class which is designed to do it.
We might need another refactor PR to handle the _original_path parameter in the GlobalConfig class.
There was a problem hiding this comment.
Let's introduce this new from_app_conf_and_app_manifest method in a separate PR, you might need to make _original_path to be Optional[str] which may cause other parts of the class to be refactored.
Code Coverage 🎉
|
| if self._is_global_config_yaml | ||
| else json.loads(config_raw) | ||
| ) | ||
| def __init__(self, global_config_path: str, **kwargs: Any) -> None: |
There was a problem hiding this comment.
@hetangmodi-crest this conflicts with https://github.com/splunk/addonfactory-ucc-generator/pull/1655/files, please review that PR first and let's merge it.
I'd like to keep the __init__ method how it is in that PR.
| source_dir: str, | ||
| app_manifest: app_manifest_lib.AppManifest, | ||
| app_conf_content: Dict[str, Any], | ||
| ) -> str: |
There was a problem hiding this comment.
It should be a classmethod and it should return "GlobalConfig".
There was a problem hiding this comment.
And please make it a separate PR after #1655 is merged.
|
Closing the PR as I'll raise a new PR once PR #1655 is merged. |
|
Raised the PR #1669 to cover the changes. |
Issue number:
ADDON-78488
PR Type
What kind of change does this PR introduce?
Summary
Generate minimal
globalConfig.jsonwhen there is noglobalConfigin source code.Changes
If any TA doesn't have
globalConfig.jsonin its source directory, then after building add-on we will be generating minimalglobalConfig.We are generating this minimal globalConfig using data present in
app.manifestandapp.conf.Achieved 100% unit test case coverage for this PR.
User experience
After this, every TA will have globalConfig in their source code.
Checklist
If an item doesn't apply to your changes, leave it unchecked.